home *** CD-ROM | disk | FTP | other *** search
/ User's Choice Windows CD / User's Choice Windows CD (CMS Software)(1993).iso / windows5 / winnet.zip / DESQVIEW.NOT < prev    next >
Internet Message Format  |  1990-05-09  |  3KB
  1. Return-Path: <nelson>
  2. From: PIRARD@BLIULG11.BITNET (Andr'e PIRARD)
  3. Newsgroups: comp.protocols.tcp-ip.ibmpc
  4. Subject: Re: enhancement to packet driver spec wanted (for desqview0
  5. Date: 7 May 90 13:07:50 GMT
  6. Organization: The Internet
  7. Apparently-To: nelson
  8.  
  9. On Fri, 13 Apr 90 15:58:04 GMT Steve Wallace said:
  10. >I'd like to propose an enhancement to the packet driver spec.  Those of
  11. >us who use multi-taskers (Desqview,  Windows, etc) are not able to
  12. >cleanly use Novell netware and other network software at the same time.
  13. >The netware shell can't be loaded in a window, therefore the packet
  14. >driver must be loaded before the multi-tasker.  Applications like telnet
  15. >will run in a window, but if there are other applications running in the
  16. >background, telnet will eventually hang.  The packet driver is executing
  17. >the function pointed to by receiver, but the real receiver is paged out.
  18. >
  19. >    It would be nice to have a modified access_type function that allowed a
  20. >software interrupt to be used as the receiver.  Applications like
  21. >telnet could be modified to support hooking an interrupt to get packets.
  22. >Desqview, and I assume others, seems to be able to deal with this type
  23. >of interface.  Any thoughts?
  24. >
  25. >
  26. >Steven Wallace
  27. >ssw@lavanix.ucs.indiana.edu
  28.  
  29. Under DESQview, communication programs should be non-swappable (to disk).
  30. Consequently, the problem exists only when multi-tasked applications
  31. reside in different switchable memory banks, available only with EEMS,
  32. "true" LIM 4.0 or QEMM386 or equivalent (probably the only comfortable
  33. environments to run network software). Else, the address space is flat.
  34. The problems to get packet drivers work with DESQview are:
  35. 1) To get the hardware interrupt to the driver, which means that either the
  36. driver must be loaded before DESQview, or that DESQview must see it grab
  37. a hardware interrupt vector it considers a "communication interrupt". When
  38. those interrupts occur, DV switches in the proper memory bank before going
  39. to the handler loaded in an application memory space.
  40. These are IRQ 2, 3, 4, 5 on AT, and 7, plus 8-15 on latest versions.
  41. 2) To get the upcall to the application, which means either the driver must
  42. be loaded within the application, or that it should take steps to switch in
  43. the correct bank much the same way as during interrupt time for (1).
  44.  
  45. Because this last point is not implemented, the driver *must* be loaded
  46. within the application, unless the address space is flat.
  47.  
  48. Running multiple applications of the same protocol (as opposed to multiple
  49. network protocols) would require that the driver contain TCP and UDP
  50. (a socket driver), and that it provide the same bank switching as (2).
  51. And a socket API used by the applications, of course.
  52. Drivers (especially socket) outside applications eat up valuable nonpaged
  53. memory. For this reason, such a scheme would require them to reside in a
  54. separate application and do the upcalls to the proper bank via a small
  55. resident code stub. And, to be even nicer, that the API suspend
  56. the applications to avoid them looping unnecessarily.
  57.  
  58. I hope these will be useful thoughts.
  59.  
  60. Andr'e PIRARD
  61. SEGI Univ. de Li`ege
  62. B26 - Sart Tilman
  63. B-4000 Li`ege 1 (Belgium)
  64. PIRARD@BLIULG11 on EARN alias BITNET
  65. pirard@vm1.ulg.ac.be as also known to Internet
  66.  
  67.